A storage system is a computer that provides storage service relating to the organization of information on storage devices, such as disks. The storage system may be deployed within a network attached storage (NAS) environment and, as such, may be embodied as a file server. The file server or filer includes a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. Each “on-disk” file may be implemented as a set of data structures, e.g., disk blocks, configured to store information. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
A filer may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the file system on the filer by issuing file system protocol messages (in the form of packets) to the filer over the network.
A common type of file system is a “write in-place” file system, an example of which is the conventional Berkeley fast file system. In a write in-place file system, the locations of the data structures, such as inodes and data blocks, on disk are typically fixed. An inode is a data structure used to store information, such as meta-data, about a file, whereas the data blocks are structures used to store the actual data for the file. The information contained in an inode may include, e.g., ownership of the file, access permission for the file, size of the file, file type and references to locations on disk of the data blocks for the file. The references to the locations of the file data are provided by pointers, which may further reference indirect blocks that, in turn, reference the data blocks, depending upon the quantity of data in the file. Changes to the inodes and data blocks are made “in-place” in accordance with the write in-place file system. If an update to a file extends the quantity of data for the file, an additional data block is allocated and the appropriate inode is updated to reference that data block.
Another type of file system is a write-anywhere file system that does not over-write data on disks. If a data block on disk is retrieved (read) from disk into memory and “dirtied” with new data, the data is stored (written) to a new location on disk to thereby optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. A particular example of a write-anywhere file system that is configured to operate on a filer is the SpinFS file system available from Network Appliance, Inc. of Sunnyvale, Calif. The SpinFS file system is implemented within a storage operating system of a filer having a overall protocol stack and associated disk storage.
Disk storage is typically implemented as one or more storage “volumes” that comprise physical storage disks, defining an overall logical arrangement of storage space.
Currently available filer implementations can serve a large number of discrete volumes (150 or more, for example). Each volume is associated with its own file system and, for purposes hereof, volume and file system shall generally be used synonymously. The disks within a volume are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). RAID implementations enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate caching of parity information with respect to the striped data. In the example of a SpinFS file system, a RAID 4 implementation may be advantageously employed. This implementation specifically entails the striping of data across a group of disks, and separate parity caching within a selected disk of the RAID group. As described herein, a volume typically comprises at least one data disk and one associated parity disk (or possibly data/parity partitions in a single disk) arranged according to a RAID 4, or equivalent high-reliability, implementation.
The filer or storage system may be configured to operate with a plurality of file-level protocols, such as the Common Internet File System (CIFS) and the Network File System (NFS) protocols to thereby enhance the utility of the system for networking clients. As such, the storage system is typically configured with a CIFS server and/or an NFS server. The NFS protocol is typically utilized by Unix-based clients to access data sets served by the NFS server, whereas the CIFS protocol is typically associated with Microsoft Windows-based clients serviced by the CIFS server. NFS and CIFS utilize differing authentication techniques for identifying access limitations to particular a data set, such as a file.
Specifically, the NFS protocol utilizes a conventional network information services (NIS) set of attributes. As such, the terms NFS attributes and NIS attributes shall be used interchangeably herein, however it is understood that NIS encompasses more than just NFS. NIS utilizes a user identifier (UID) and a primary group identifier (GID) for authentication. To that end, the UID and GID are sent from the client to the NFS server with every NFS operation containing a data access request. The NFS server compares the received UID and/or GID with permissions associated with a particular file. The NFS server does not perform any additional authentication, but simply accepts the UID/GID that is asserted by the client when sending the data access request. In an exemplary NFS environment, the permissions associated with a file are stored as mode bits, which are divided into three fields, namely the permissions associated with the owner, with the group, and with others. Each of the three fields contains three bits, one for read access, one for write access, and one for execute permission. NFS mode bits for permissions are further described in Request for Comments 1094: Network File System Protocol Specification, by Bill Nowicki, March 1989, the contents of which are hereby incorporated by reference.
The CIFS protocol does not trust the client to transmit the correct credentials with a data access request. In a CIFS environment, user identifiers are not UIDs as utilized by NFS but comprise security identifiers (SIDs), which are unique on a worldwide basis. One or more identification authorities authenticate a given SID, as described further below. When a CIFS command arrives at the CIFS server, the credential is compared with an access control list (ACL). An ACL consists of zero or more access control entries (ACE). Each ACE consists of a SID, which identifies the person or group to which the ACE applies, and a set of permissions, which can identify access allowance or denial. Thus, an ACE may identify a particular SID and denote that access is not to be granted to the person(s) identified by that SID.
A noted disadvantage arises when a file is generated by a client of the storage system utilizing the NFS protocol and, at some later point in time, a user or client utilizing the CIFS protocol desires to view the ACL and/or other permissions of the file. As the file was generated by a NFS client, no ACL was generated during file creation. What is needed is a technique for associating NIS attributes with CIFS clients.